The design of a graphical user interface (GUI) generally involves the use of application programming interfaces (APIs) which are written to satisfy business logic. The business logic is tied to the expected conduct of the application that the GUI will support. Alternately, a GUI is developed to directly contain business logic to make the GUI function specifically for the target application. There are several drawbacks to this common approach. One drawback is that there is no easy way to access the business logic outside of the GUI. The GUI must be accessed in order to use the business logic that the GUI contains. Another drawback is that there is no symmetry between GUI and APIs which are available outside of GUI. There is no guarantee that other, non-GUI portions of code have access to the same business logic rules and program solutions. For example, in current GUI programming environments, little or no attention paid to command line (cmdline) interface. Thus there is usually a difference in performance experience between the use of the GUI and the cmdline.
One consequence of placing business logic into a GUI is that the GUI code is hard to maintain as business logic. This is evident because internal product operations are intermixed with presentation logic such as the GUI visuals. Accordingly, GUI and APIs are hard to maintain and develop as they are hard coded to specific scenarios. When a “hotfix” or service pack is applied, the GUI has to be changed to accommodate fixes in the business logic.
Another consequence of placing business logic into a GUI is that the application product team is constrained in what can be added to GUI after release. Since the business logic is hard coded into the GUI, it is hard to add new features or adjust visuals over time. The application product development cycle is also restricted for management testing and development because the GUI has to be built before any testing of the management of a feature can be done. Since the GUI is traditionally completed towards the end of a product cycle, this can be risky because application testing does not usually occur for managing a feature until the GUI is available. When the GUI is scheduled late in the development process, critical test may be delayed. Also, if validation logic is embedded in the GUI, it may not be reusable if a GUI visual or business logic change is made.
Thus there may be an advantage to designing an GUI such that the visual features are abstracted away from all business logic. However, no methodology or infrastructure exists to do so in a generic manner that is applicable to any variety of operations. In the past, APIs have been designed to be generic, but quickly devolve into library functions for the GUI, which still poses the same problems noted previously.